Amazon FSxで新しいストレージクラスであるAmazon FSx Intelligent-Tieringが発表されAmazon FSx for OpenZFSで使用できるようになりました #AWSreInvent
2024.12.03Amazon FSx for NetApp ONTAP以外のFSxシリーズでも階層化を行いたい
皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)以外のFSxシリーズでも階層化を行いたいと思ったことはありますか? 私はあります。
FSxNでは階層化を用いることで、最終アクセスから経過した日数によって安価なストレージ階層に透過的に階層化し、コストを大幅に削減することが可能です。
詳細は以下記事をご覧ください。
階層化は同様にFSxシリーズの中ではFSxNのみの機能でした。
これが今回、Amazon FSx Intelligent-TieringがGAされ、Amazon FSx for OpenZFS(FSxZ)で使用できるようになりました。
AWS Blogsにも投稿されていますね。
これによりFSxNの階層化との違いも気になりますね。
早速確認してみました。
Amazon FSx Intelligent-Tiering とは
Amazon FSx Intelligent-TieringとはAmazon FSx の新しいストレージクラスです。
これでFSxで選択可能なストレージクラスは以下の3種類となりました。
- SSD
- HDD
- Amazon FSx Intelligent-Tiering
※ キャパシティプールストレージは直接ストレージクラスとして使用できないためここには含めず
Amazon FSx Intelligent-Tieringは内部的に以下の3階層が存在しているようです。
- 高頻度アクセス (キャッシュ)
- 低頻度アクセス
- アーカイブ
高頻度アクセスがSSDベースのストレージです。
階層化はブロックレベルで行われます。ローンチブログによると、低頻度アクセスストレージには30日以上アクセスがないデータブロック、アーカイブストレージには90日以上アクセスがないデータブロックに階層化されるようです。(後述するドキュメントには具体的な説明がないため確証はありません)
Amazon FSx Intelligent-Tieringのメリットはやはりコスト削減です。
FSx Intelligent-Tieringを使用することで、SSDストレージクラスよりも最大85%、オンプレミスの従来のHDDベースのNASストレージよりも最大20%コストを削減することが可能とされています。
具体的にどのぐらいのコストなのか気になるところですが、残念ながら2024/12/2時点では料金表に記載されていませんでした。記載されることを期待して待っておきましょう。
また、FSx Intelligent-Tieringを利用するメリットがプロビジョニングするストレージ管理コストの削減です。
スループットキャパシティに応じて自動でSSDのサイズが変動します。加えて嬉しいのはSSDがキャッシュであるため、SSDサイズを増強するだけでなく、削減することも可能です。
キャッシュが不要なのであればSSDを用意しない形にすることだって可能です。これはアツい。
注意点
注意点は以下のとおりです。
- Intelligent-Tiering ストレージからのデータアクセスは高いレイテンシーとリクエストごとのコストがかかるため、I/Oサイズを考慮してワークロードとファイルシステムを構成する必要がある
- 小さいI/Oサイズでデータを読み取るワークロードは、大きいI/Oサイズを使用するワークロードと比較して、キャッシュにないデータに対して同じスループットを達成するために、より高い同時実行性が必要で、より多くのリクエストコストが発生する
- ワーキングセットがSSDキャッシュのサイズより大きいワークロードの場合、アプリケーションのI/OサイズとFSxボリュームのレコードサイズを最大化することを検討
- ファイルシステムへの書き込みは、クライアントに提供される前にメモリ内キャッシュ（非同期書き込みの場合）またはSSD書き込みキャッシュ（同期書き込みの場合）にのみ保存されるため、書き込みI/Oについてはそれほど考慮する必要はない
- メンテナンスイベント後に高いレイテンシーが発生する可能性が高くなる
- Intelligent-Tiering ストレージクラスを使用するファイルシステムのメンテナンスウィンドウ中にメモリ内キャッシュが消去されるため
- Intelligent-Tiering ファイルシステムでクライアントが実現できる最大ディスクIOPSは、ワークロードの特定のアクセスパターンとSSD読み取りキャッシュをプロビジョニングしているかどうかによって異なる
- ランダムアクセスのワークロードの場合、データがSSD読み取りキャッシュにキャッシュされている場合、キャッシュにない場合と比べてクライアントは通常はるかに高いIOPSを実現可能
- Intelligent-Tiering ストレージからのランダム読み取りリクエストは、データがプリフェッチを通じて事前ではなくジャストインタイムで提供されるため、シーケンシャル読み取りリクエストよりも高いレイテンシーとなる
- 可能な場合は、データのプリフェッチとより高いパフォーマンスを実現するために、データアクセスパターンをシーケンシャルに構成することが推奨
注意点やパフォーマンスは以下AWS公式ドキュメントにまとめられています。
対応リージョン
対応リージョンは以下のとおりです。東京リージョンもサポートしています。
- バージニア北部
- オハイオ
- オレゴン
- カナダ
- フランクフルト
- アイルランド
- ムンバイ
- シンガポール
- シドニー
- 東京
やってみた
実際にやってみます。
ストレージクラスをIntelligent-TieringでFSxZを作成します。
Intelligent-Tieringとした場合はMulti-AZ構成とする必要があるようです。また、スループットキャパシティはミニマムで1280MBpsでした。Elasticとはいえ、かなりのスループットを求められる環境が対象なのかもしれません。
SSDのサイズはスループットキャパシティと連動するようにした場合、どのような値になるのか気になりますね。
Multi-AZ構成であるため、フローティングIPを動作させるためのルートテーブルやエンドポイントIPアドレス範囲を指定しています。
ルートボリュームおよび以降の設定はデフォルトのままです。
確認です。後からストレージクラスを変更することはできないようですね。
作成中は以下のとおりです。SSDのサイズは6,400GiBでした。かなりの大容量です。スループットキャパシティ1MBpsあたり5GiBのようですね。
数十分ほどで作成が完了しました。
せっかくなのでキャッシュSSDを縮小させてみましょう。
すると、数十分ほどで64GiBに縮小できました。これはありがたいですね。
ハイパフォーマンスが求められるが、データブロックの参照期間が短いようなワークロードに
新しく発表されたAmazon FSx Intelligent-Tieringの紹介をしました。
ミニマムのスループットキャパシティが1,280MBpsとそれなりに大きいため、ハイパフォーマンスなワークロードにマッチすると思います。
加えて、一度書き込まれたデータブロックが1週間などある程度の期間経過すると、アクセス頻度が落ちていくようなワークロードだと、さらにコストメリットを感じることができるでしょう。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] Amazon FSx for OpenZFS がファイルシステム間で On-demand data replication をサポート開始 #AWSreInvent](https://devio2023-media.developers.io/wp-content/uploads/2023/11/eyecatch_english-reinvent-2023-newservice.png)
![[アップデート] Amazon FSx for OpenZFSでMulti-AZ構成がサポートされました](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-open-zfs-1.png)
